A supply chain planning problem can be defined, for example, as a series of planning problems that typically includes such problems as (1) demand forecasting, (2) service level planning, and (3) replenishment planning. Demand forecasting is a method used to project the future demand for a particular item at a particular location, based on historical sales information. Service level planning is a method used to compute safety stock limits and ordering policies for items, based on customer service levels for the items and their future demand. Replenishment planning is a method used to generate suggested purchase orders and distribution orders for items, based on the future demand and actual orders for the items, but still respecting the safety stock limits for the items and other supply chain constraints imposed.
The size of a supply chain planning problem is typically measured by (1) the number of locations within the supply chain, (2) the number of items in the supply chain, (3) the length of the planning period, and (4) the complexity of the business rules imposed. For example, in the retail industry, a retailer might have to manage an inventory of more than 100,000 items at 1,000 locations for a period of 26 weeks. As the magnitudes of these numbers indicate, a large-scale supply chain planning problem involves the processing and movement of enormous amounts of data. Typically, supply chain planning data (e.g., inventory item information) can be stored in a relational database.
FIG. 1 illustrates a typical supply chain planning system 10. When a planning process application 12 (e.g., planning application software executed by a computer processor) is initiated, the application reads, via a suitable transmission link 14, the data needed for a planning problem from a database 16. Next, the planning process application 12 solves the planning problem by applying one or more planning algorithms to the retrieved data, in accordance with any supply chain constraints imposed. The results of the planning process 12 (e.g., solutions to the planning problem or problems) are then written, via a suitable link 18, to the database 16.
Unfortunately, large-scale, supply chain planning is not performed very efficiently using only one planning process. For example, as illustrated by FIG. 1, in order to solve a large-scale, supply chain planning problem, all of the data maintained for all items at all locations have to be read from a single database and processed. Then, the solutions or resulting data have to be written back to that database. Consequently, for a supply chain with a relatively large number of items and locations, the volume of data to be processed and conveyed to/from the database is tremendous. In fact, for such a large dataset, the planning process and database read/write operations for a conventional system require an exceedingly large amount of processing time.
FIG. 2 illustrates how a planning process for a large scale supply chain can be performed more rapidly than the planning process shown in FIG. 1. In FIG. 2, a large planning problem is solved by a plurality of planning processes 22, 24, 26. The planning processes 22, 24 and 26 are performed simultaneously. For example, each planning process 22, 24, 26 reads a respective subset of data from the database 28, and then solves the planning problem by applying planning algorithms to the respective data subsets and the supply chain constraints imposed. Finally, each planning process 22, 24, 26 writes the respective results (e.g., solutions to the planning problem) to the database 28.
As illustrated by FIG. 2, although the simultaneous use of multiple planning processes may improve the scalability (ease with which a system can be modified to accommodate increases in system loads and transaction complexity) of large scale planning systems to a certain extent, the simultaneous reads and writes of the large subsets of data to and from the database by the multiple planning processes create a severe bottleneck for the flow of data at the database. As such, the number of read and write operations that can be performed by multiple planning processes to a centralized database, such as database 28, is not proportional to the number of planning processes used. In fact, centralized databases typically behave anti-proportionately as more and more processes are used which read and write data, because of thrashing (degraded performance because miss rate too high) and the negative performance effects of read/write contentions. Therefore, the overall performance of a system using multiple planning processes versus a single planning process for large scale supply chain planning is not significantly improved.